When a program is being executed by a processor, the instructions of the program read from, and write to, a set of shared registers (e.g. a main register set). When an exception (i.e. an anomalous or exceptional condition requiring special processing) occurs the normal flow of program execution is interrupted and the program typically jumps to exception handling instructions which implement an exception handler. For example, as shown in FIG. 1, if an exception 102 occurs when instruction A 104 of a main program 106 is being executed, the processor may jump from the main program 106 to an exception handler 108.
The exception handler 108 may cause the processor to write to and read from the main register set 109 as it processes the exception. However, since the main program 106 is written as if there are no exceptions (i.e. if instruction A 104 writes 5 to register X then if instruction B 112 subsequently reads from register X then instruction B 112 expects to read the value 5) it is important that before an exception is processed (e.g. by the exception handler 108) the state of the main register set 109 is preserved so that when the main program 106 is resumed the state of the main register set 109 can be restored so that the main program 106 can continue as if the exception had not occurred.
Accordingly, the exception handler 108 typically causes the processor to save the state of the main register set 109 before processing the exception to allow any changes made to the main register set 109 while processing the exception to be undone. The exception handler 108 then causes the processor to process the exception (e.g. the exception handler 108 may invoke a subroutine 110 for handling the specific type of exception) using the main register set 109 (e.g. writing to and reading from the main register set 109). Once the exception has been processed the exception handler 108 causes the processor to restore the main register set 109 and (where appropriate) return to executing instructions of the main program 106 (e.g. return to instruction B 112). However, saving and restoring the main register set 109 before and after processing an exception takes a significant amount of time.
To reduce the exception response time, the concept of banked or shadow registers were developed. Banked or shadow registers are a separate set of registers that are used for processing exceptions, or for processing certain types of exceptions. Since a separate register set is used to process exceptions (or certain types of exceptions) there is no need to save and restore the main register set before processing an exception (or the specific type of exception).
For example, as shown in FIG. 2, the processor may be configured to execute instructions of a main program 202 using a first or main register set 204 (e.g. writing to and reading from the main register set 204). When an exception 206 occurs during processing of instruction A 208 of the main program 202, an exception handler 210 may be invoked. Instead of causing the processor to save and restore the main register set 204, the processor is configured to execute the exception handler 210 (e.g. which may invoke a subroutine 212 for handling the specific type of exception) using a second or shadow register set 214 (e.g. writing to and reading from the shadow register set 214). Once the exception has been processed the processor returns to the main program 202 (e.g. to instruction B 216) where it goes back to using the main register set 204 (e.g. writing to and reading from the main register set 204). While this significantly reduces the overhead and reduces the effective latency associated with exceptions, the shadow register set 214 requires extra hardware to implement.
This problem is exacerbated when there are multiple nested exceptions because there is typically one shadow register set for each level of nested exception. Nested exceptions occur when certain exceptions (e.g. high priority exceptions) may interrupt processing of other exceptions (e.g. low priority exceptions).
The embodiments described below are provided by way of example only and are not limiting of implementations which solve any or all of the disadvantages of known methods of handling exceptions.